Cost Control Tips How To Pay For Korean Cloud Servers Combining Prepaid And On-demand Models To Optimize Expenses

1.

overview: why combining prepaid (reservation) and on-demand reduces costs

- theoretical points: prepaid (reservation, annual and monthly subscription, purchasing prepaid coupons) is suitable for stable basic loads, and on-demand is suitable for sudden and elastic loads.
- practical significance: use prepaid lock-in prices for long-term stable consumption, and use on-demand or spot instances (spot) for short-term peak consumption, which can maximize savings under controllable risks.

2.

step 1: obtain and export historical bills and indicators (required)

- operation steps: log in to your korean cloud service console (such as ncp, kt cloud, aws seoul, etc.), enter the "billing" page, and export the csv or bill details of the last 3 to 6 months.
- key points of data items: at least include cost per instance per hour, instance type, startup time, traffic, disk snapshots, and object storage fees. if the cloud provider supports cost explorer or bill analysis tools, it can directly export daily/hourly granular usage data.

3.

step 2: analyze and distinguish between "basic stable load" and "fluctuating load"

- method: aggregate the exported hourly cpu/traffic/disk io by instance, and calculate the number of continuous online hours and 95th percentile utilization of each instance within a week.
- judgment rules (practical experience value): if an instance is online for >70% of the time per month and the cpu/memory usage is stable for a long time (fluctuation is less than 30%), it is considered a candidate for prepayment; otherwise, the on-demand or elastic strategy is retained.

4.

step 3: calculate the prepayment ratio and capital recovery critical point (with formula example)

- formula: monthly prepaid cost = reserved unit price (month) × number of reserved instances; monthly on-demand cost = on-demand unit price × number of instance hours/number of hours per month (approximately 730).
- example calculation: assume that the on-demand unit price is 0.10 usd/hour and the reserved monthly price is 60 usd/month (equal to 0.082 usd/hour): if the instance runs 730 hours per month, on-demand = 73 usd, reserved = 60 usd, a single instance saves 13 usd per month (about 18%). when deciding on reserved quantities, multiply the expected long-term operating hours by the on-demand price versus the reserved price.

5.

step 4: purchase prepaid/reserved resources on the console (step-by-step operation)

- operation process (general): 1) console → billing/reserved instance → select the region (select south korea/seoul) → select the instance specification and lease period (1 year/3 years) → select the payment method (one-time payment or monthly deduction, if available) → confirm the purchase.
- note: use a small amount of testing first (for example, reserve half of the 70% estimated base), confirm it is correct, and then add; keep the undo/modify window to understand whether convertible/returnable reservation types are supported.

6.

step 5: set up automatic expansion and contraction and on-demand strategies (practical configuration points)

- operation steps: enable auto scaling behind the application layer or load balancer: define the minimum number of instances (it is recommended to be the same as or slightly higher than the number of reserved instances), the expected number of instances, and the maximum number of instances (to reserve space for peaks).
- elastic strategy: use on-demand or spot instances (non-critical tasks) for expansion. set a policy such as cpu >70% for 5 minutes to trigger expansion; set the shrink delay to 10~15 minutes to avoid jitter.

7.

step 6: use bidding/spot instances to save batch processing costs (implementation process)

- applicable scenarios: non-interactive, interruptible tasks (etl, offline training, video transcoding).
- operation suggestions: set spot priority in the startup template, set a price limit, configure an automatic fallback strategy (fallback to on-demand when spot is insufficient), and retain a mechanism to automatically save intermediate states.

8.

step seven: instance tuning and right sizing

- steps: use monitoring data (cpu, memory, network, disk) to determine whether there is over-provisioning: if the cpu is lower than 30% for a long time and the memory is not full, you can downgrade or merge services.
- tools and operations: use the rightsizing report recommended by the cloud vendor, or write your own script (call the monitoring api) to list long-term low-utilized instances and include them in the downgrade/shutdown plan.

9.

step 8: scheduled power on/off strategy (save night/weekend costs)

- simple implementation: write cloud api scripts or use the cloud vendor's scheduled tasks: example - close non-essential development/test instances at 22:00 every day and start them at 09:00 the next day.
- script example (pseudocode): call the api to list instances labeled "dev", and press cron to trigger stop/start. make sure there is data persistence before shutting down (do not stop the database/shared disk accidentally).

10.

step 9: storage and snapshot optimization (avoid hidden costs)

- operation points: clean up unused eips, idle disks, expired snapshots, and set object storage lifecycle rules to automatically transfer cold data to cold storage/archives.
- practical operation: set rules in the object storage bucket: transfer to cold storage in 30 days, transfer to archive in 180 days; regularly audit snapshots and automatically delete snapshots that have not been mounted for more than n days.

11.

step 10: network and egress traffic optimization

- method: enable cdn to cache static content, enable compression (gzip/brotli) on the application side, and merge requests to reduce cross-zone requests.
- billing optimization: put high-traffic static content into object storage and distribute it through cdn to reduce cloud server public network export traffic costs.

12.

step 11: establish budget, alarm and automated response mechanisms

- practical operation: set budget thresholds in the billing center (such as sending emails/text messages/webhook when the monthly expenditure reaches 70%/90%/100%), and associate automated playbooks (such as suspending non-core instances and shrinking non-production environments).
- monitoring tools: enable daily cost reports and set weekly review emails to responsible personnel.

13.

step 12: monthly review and adjustment (process list)

- key points list: 1) export the monthly bill and compare it with the budget; 2) check whether the prepaid to on-demand ratio is still reasonable; 3) review whether the newly online instances have been tagged and classified into the prepaid/on-demand policy; 4) update the prepaid purchase plan.
- frequency of practical operation: the key is continuity, summarize once a month and adjust the purchasing strategy every quarter.

14.

step 13: typical mixed strategy examples and numerical demonstrations

- example strategy: 70% of the basic load is prepaid, and 30% of the peak load and burst use on-demand + spot; if the base is 2 m4.large online for a long time, prepayment based on the above example can save about 15~25%.
- evaluation steps: 1) count the basic hours; 2) calculate the savings using the prepaid price; 3) set safety redundancy (the prepaid number should not fill the limit, leaving a 20% on-demand margin).

15.

step 14: implementation precautions and risk control

- risk points: prepayment period lock-in may cause waste when specifications/architecture changes are made; spot recycling may affect tasks.
- mitigation: reserve a certain on-demand budget, do a small pilot before purchasing a reservation, use convertible reservations (if supported by the cloud vendor).

16.

faq 1: how should the lease term (one year or three years) be determined when choosing prepayment?

a: if the business is stable and no large-scale structural changes are expected within three years, three years is usually a higher discount but less flexible. it is recommended to focus on one year first, and then consider three years after verifying that the architecture is stable; if the cloud vendor supports the "convertible" or "partial refund" plan, you can give priority to longer lease periods to get lower prices.

17.

faq 2: how to calculate the "critical number of prepaid hours" to determine whether to reserve an instance?

answer: critical hours = reserved monthly price ÷ on-demand hourly price (direct comparison can be made when the monthly hours are close to 730). specific steps: multiply the average monthly running hours of the instance in the past three months by the on-demand price and compare it with the reserved monthly price. if the on-demand cost is higher than the reserved price, consider upfront payment.

18.

faq 3: how to ensure that key services are available if the spot instance is recycled?

answer: adopt a hybrid strategy: use reserved or on-demand instances for key services, use spot for batch processing tasks, and configure automatic fallback to on-demand in the spot template; at the same time, achieve task checkpoint/intermediate result persistence to ensure that you can continue from the breakpoint after retrying or migrating.